One of the major causes for the current commercial applications being not flexible enough lies in the inseparable and unmanageable tangle of function concerns and non-function concerns, wherein the function concerns refer to commercial functions and logics while the non-function concerns refer to the aspects such as performances, security, monitoring, and extensibility. For the program codes, the crosscutting of function concerns and non-function concerns increases the complexity significantly and results in difficulty in comprehension, construction, expansion, and reuse, for example:                Comprehension: The commercial logic codes are woven with the codes related to NFR (non-function requirement), so it is difficult for people to comprehend the codes from a single prospect;        Construction: It is necessary to develop codes prudently to take into account the function aspects and non-function aspects, and higher work load and more skills are required accordingly;        Expansibility: It is fairly difficult to modify codes in case function or non-function demands vary;        Reuse: It is very difficult to reuse function or non-function codes only.        
Consequently, just as the still more detailed explanation presented as follows, the separation of concerns becomes the major targets and path for modern software technologies including AOP (Aspect Oriented Programming) and J2EE (Java™ 2 Platform Enterprise Edition Specification) etc. However, utilization of these technologies is confronted with extreme restraint. On the one hand, AOP can only process simple NFR tasks such as log. On the other hand, even though a container is introduced into J2EE such that the latter may process complicated NFR issues (for instance, transaction), it is generally time consuming to add such NFR supports, and it also requires adequate understanding of container implementation and relevant skills. It is fairly difficult to implement customization support and specialized NFR support in the current J2EE containers, resulting in a fact that only some general NFRs are supported in J2EE, with the remaining NFRs still mingled with the function codes.
AOP is a programming paradigm that was presented in 1990s by Xerox PARX Company. AOP enables the developer to separate the concerns. Many non-function services such as log, security inspection, and transaction management etc. are thus separated from function services. Moreover, function services may share these non-function services. In case non-function behavior varies, these function services require no amendment, and only the non-function services require amendment.
According to the results of investigation conducted by AOSD (Aspect-Oriented Software Development, relevant reference is available in the Internet website aosd.net), there are approximately 100 kinds of AOP implementations For AOP implementation based on Java, there are over 20 kinds of implementations. Several kinds of relatively mature AOP implementations are hereby listed as follows:
1. AspectJ
AspectJ (trademark) (relevant reference is available on Internet website eclipse.org under aspectj) is a type of general aspect-oriented extension of Java. Prior to being disposed, AspectJ may conduct weaving while compiling. AspectJ is a type of static weaving that utilizes a pre-compiler to enhance the source codes. AspectJ is a type of mature AOP implementation, however, it is very complicated and requires a special-purpose Java compiler.
2. AspectWerkz
AspectWerkz (trademark) (relevant reference is available on Internet website aspectwerkz.codehous.org) is a type of dynamic AOP framework. AspectWerkz may modify Java byte codes in order to implement aspect weaving. Weaving takes place in two different phases, of which, one phase is a class loading phase, and the other is an activating phase.
3. SpringFramework
SpringFramework (trademark) (relevant reference is available on Internet website springframework.org under documents/wiki/Spring AOP Framework) is a type of AOP framework based on dynamic proxy, in which the dynamic proxy comes from proxy design mode. Dynamic proxy need not generate a proxy for each active service object. It has to fulfill proxy generating for the interfaces and proxies to be activated, and the runtime will generate the proxy object. SpringFramework uses as default the proxy mechanism provided by JDK.
4. JBoss AOP
JBoss AOP (trademark) (relevant reference is available on Internet website jboss.org under products/aop) uses Javassist to modify the byte codes so as to implement dynamic weaving during class loading.
For the known AOP implementation, the non-function portion (aspect) is still programmed with codes. The respective aspects and function codes are woven together in runtime or compiling to generate hybrid codes. Therefore, each aspect will be loaded into the memory with function code. If several function codes use one aspect and these function codes are all in the memory, the memory may have several copies of the aspect. Besides, no plug-in framework is utilized for providing AOP implementation of extension mechanism for aspect.
For instance, in some application containers of J2EE (Java™ 2 platform enterprise compiling specifications v1.4) container (relevant reference is available on the javasun website), some non-function portions that the application programs utilize frequently are separated and provided by container. At present, J2EE container supports the non-functions including authentication, transaction, and log etc. However, current J2EE does not provide an extension mechanism and framework in order to allow a third party to extend these non-function services implementations and weave them into applications.
In a book titled as “Lightweight plug-in-based application development” published in 2002 by Mayer et al., the plug-in concept was put forward as a design mode (the design mode described in the book adopted the form put forward by a book titled as “Design Patterns: Elements of Reusable Object-Oriented Software” published by Gamma et al. in 1995), and exemplary implementations in Java were given. Its architecture includes the plug-in managers of loading classes and identifying the classes that utilize reflection to implement the known interfaces as a main interface, and its relevant contents are presented detailedly in a technical report titled as “The Reflection API” published by Green et al. in Sun Microsystems, Inc. in 1997-2001, which is available on the javasun Internet website under docs/books/tutorial/reflect. The exemplary implementations proposed by Mayer et al. allow utilization of multiple plug-ins and different interfaces to extend a certain application, however, it fails to mention that plug-ins may be added to other plug-ins.
PluggableComponent provides a mode of infrastructure or architecture that allows component exchange at runtime, and relevant contents are presented in detail in an article titled as “Pluggable Component—A Pattern for Interactive System Configuration” published by Völter in EuroPLoP'99 in 1999. Characteristics of the architecture lie in registry for managing PluggableComponent of different types. The registry provides the administrator through configuration tools with a list used for configuring available components for his applications.
Eclipse platform was designed for constructing an integral development environment, its relevant contents are presented in detail in a technical report titled as “Eclipse Platform Technical Overview” published by Object Technology International, Inc. in July 2001, and the article is available on the eclipse.org Internet website under eclipse-overview. Eclipse platform is based on the mechanism that is utilized to find out, integrate, and run the components that are referred to as plug-ins. Any plug-in may define freely new extension points (relevant descriptions are also available on the above-mentioned website) and provide new API for other plug-ins. Plug-in may extend the functions of other plug-ins and extend the kernel. This provides flexibility in creating still more complicated configuration.
However, all these plug-in frameworks function on the application layer. A user request includes a designator that shows which plug-ins should be included in order to meet the request. However, in application containers, information on which non-function plug-ins should be invoked may not be given directly in only the user request.
In the USA patent application filed by Gupta et al. and published as No. US2007/0124797A1 on May 31, 2007, a method to create, manage, and execute policy in network service environment and a system for applying the system are disclosed, and these intended to separate functional logic from non-function logic as well. The system includes a policy manager, a policy executor, clients, and services. Client includes the software for requesting the services. The services indicate network services such as log-in application or operable (functional) process, and the interfaces and encryption of messages. Policy manager is applicable to designated functions such as log, authentication, encryption, and cache etc., which are not core commercial logics but provide non-function contribution really. Policy manager is used in separating commercial concerns from non-commercial concerns. Policy executor is used in monitoring and executing the policy that are configured by the policy manager. Policy manager is implemented in the application layer of OSI (open system interconnection) 7-layer model in the system, and the created policies are executed in the lower layers. No modification is made to lower layers of the network in the system. In the system, policy may be implemented as a message interceptor, so the policy may be introduced into the message flow path seamlessly. Or, the policy may be deployed into the gateway and service proxy. Gateways and proxy may intercept messages in order to implement the corresponding policy. According to the above-mentioned contents, it is obvious that the system disclosed in the patent application utilizes a policy manager to configure and meet the non-function demands, however it fails to provide an extensible method to allow the developer to extend and customize the supports for non-function demands. Besides, the method disclosed in the patent application locates the policy manager between the client and backend services, so that only the access to service interfaces can be controlled in fact, and the control of access between multiple services requires adding multiple policy managers accordingly, resulting in higher complexity of network implementation and higher implementation cost and time consumption.
Therefore, the existing technologies need a mechanism that allows easy, quick, and extensible separation of functional logic from non-function logic.